Skip to content

Fix loadedCallbackPending logic to properly prevent frame invalidation during Unity player creation #1020

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Fix loadedCallbackPending logic to properly prevent frame invalidation during Unity player creation #1020

wants to merge 1 commit into from

Conversation

dev-aman
Copy link

@dev-aman dev-aman commented Jun 2, 2025 •
edited
Loading

Description

Problem

The loadedCallbackPending variable was not being properly managed, causing potential race conditions and unnecessary frame invalidation calls during Unity player initialization. The guard condition in invalidateFrameIfNeeded() was ineffective because:
The variable was never being set to true and also it resets to false immediately after the guard check instead of when the callback actually completed.
This could lead to frame invalidation attempts while Unity player creation was still in progress

Solution

  • Properly set loadedCallbackPending = true when Unity player creation begins
  • Reset loadedCallbackPending = false only when the OnCreateUnityViewCallback.onReady() is called or on error
  • Remove the incorrect reset in invalidateFrameIfNeeded() method

Related Issues

Fixes potential race conditions during Unity player initialization that could cause rendering issues or crashes.

Type of Change

  • ✨ New feature (non-breaking change which adds functionality)
  • 🛠️ Bug fix (non-breaking change which fixes an issue)
  • ❌ Breaking change (fix or feature that would cause existing functionality to change)
  • 🧹 Code refactor
  • ✅ Build configuration change
  • 📝 Documentation
  • 🗑️ Chore

@timbotimbo
Copy link
Collaborator

timbotimbo commented Jun 5, 2025 •
edited
Loading

Hmm, this is a workaround for a bug introduced in Flutter 3.0 and I wonder if it is still needed at all.

Out of curiosity, did you run into a bug or performance issue that made you look into this? Or did you simply spot something weird in the source code?

Some context.

  • Before 3.0 Flutter had 2 platform view modes: Hybrid Composition HC) and Virtual Display (VD).
    The useAndroidViewSurface param in this plugin toggles between the two, with VD being the default.

  • Flutter 3.0 replaced VD with a new mode (TLHC), which broke on SurfaceViews like Unity is using.
    This plugin temporarily switched the default to HC to avoid being fully broken (plugin v2022.1.1).
    (The google maps plugin changed their default too).

  • This workaround was added in google_maps_flutter to fix some issues caused by TLHC.
    And it looks like a variant of that was added to this plugin.

  • Flutter 3.3 added a TLHC -> VD fallback when using a SurfaceView, so this plugin returned to the old behaviour.
    Plugin version 2022.2.0 switched the default back to VD because the Flutter 3.3 fix worked.

There's a chance that this workaround (if it works at all) is redundant after Flutter 3.3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@dev-aman @timbotimbo